Findings

• [Major] Resume can target wrong machine when metadata.machineId or metadata.host mismatches; fallback to first online uses metadata.path on another machine. Evidence hub/src/sync/syncEngine.ts:353.
  Suggested fix:

  const targetMachine = (() => {
      if (metadata.machineId) {
          const exact = onlineMachines.find((machine) => machine.id === metadata.machineId)
          if (exact) return exact
          return null
      }
      if (metadata.host) {
          const hostMatch = onlineMachines.find((machine) => machine.metadata?.host === metadata.host)
          if (hostMatch) return hostMatch
          return null
      }
      return onlineMachines[0]
  })()
  
  if (!targetMachine) {
      return { type: 'error', message: 'No matching machine online', code: 'no_machine_online' }
  }

Summary

• 1 issue. Resume safety risk on multi-machine namespaces.

Testing

• Not run (automation)

Thanks for the fix — the root + bypassPermissions rejection is a real issue. I ran into a related problem in #406 (now merged) where exit_plan_mode handling depends on canCallTool being the permission mechanism, so your Change 1 logic is architecturally correct.

However, this PR bundles three unrelated changes and has gone stale. Here's my review per change:

Change 1: query.ts — skip --permission-mode when canCallTool + bypassPermissions

Logic is correct — when canCallTool is provided, HAPI handles permissions via the stdio protocol. Passing --dangerously-skip-permissions is redundant and crashes under root.

But the diff is stale. PR #343 (merged 2026-03-23) rewrote large parts of `query.ts` — the stderr handling, close handler, and cleanup changes in your diff are already on main. This will have significant merge conflicts. Needs a rebase keeping only the `permissionMode` condition change.

Change 2: `claudeRemoteLauncher.ts` — improve error logging

Good fix. `JSON.stringify(new Error(...))` produces `'{}'` because Error properties are non-enumerable. Your explicit extraction of `e.name`, `e.message`, and `e.stack` is the correct approach. This change is clean and mergeable.

Change 3: `syncEngine.ts` — fallback to first online machine

This is risky. When `metadata.machineId` is set but doesn't match any online machine, falling back to `onlineMachines[0]` means the session resumes on a different machine. In multi-machine setups this can silently resume in the wrong context (wrong repo, wrong state).

The bot flagged the same issue and suggested a safer approach — only fall back when there's no machineId/host constraint:

```ts
if (metadata.machineId) {
const exact = onlineMachines.find((machine) => machine.id === metadata.machineId)
if (exact) return exact
return null // specific machine requested but not found
}
if (metadata.host) {
const hostMatch = onlineMachines.find((machine) => machine.metadata?.host === metadata.host)
if (hostMatch) return hostMatch
return null // specific host requested but not found
}
return onlineMachines[0] // no constraint, safe to fall back
```

Suggestions

1. Split into separate PRs — the three changes are independent. A focused PR per fix would be easier to review and merge.
2. Rebase Change 1 on current main — only the `permissionMode` condition is needed, the rest of the `query.ts` changes are already merged via #343.
3. Rework Change 3 per the bot's suggestion to avoid the multi-machine safety issue.
4. Change 2 can be submitted as-is — it's clean and self-contained.